feat(blueprints): add Blueprint-specific service settings - #2965

Adds Blueprint-specific settings, metadata, and update-preview workflows for Terraform- and Helm-based services.

Changes:

• Adds Blueprint configuration routing, navigation, persistence, validation, and optimistic updates.
• Refines Blueprint metadata and update-preview modal behavior.
• Updates shared modal APIs, generated client dependencies, and tests.

Suppressed comments (10)

apps/console/src/routes/_authenticated/organization/$organizationId/project/$projectId/environment/$environmentId/service/$serviceId/settings/blueprint-configuration.tsx:21

• For a non-Blueprint service, this route returns null, leaving a blank settings content area when the URL is opened directly or from a stale link. The other service-specific settings routes redirect unsupported services to General; this route should do the same instead of rendering nothing.

  if (!organization || !service || !isBlueprintService(service)) {
    return null

libs/domains/service-settings/feature/src/lib/service-general-settings/blueprint-general-settings/blueprint-general-settings.tsx:304

• The successful update path only shows a toast; it never emits the blueprint_settings_updated event promised in the PR description (and no such event exists elsewhere in the checkout). Capture it after both the update and deploy mutations succeed, so failed operations are not counted.

    try {
      await updateBlueprint({ blueprintId: service.blueprint_id, payload })
      await deployBlueprint({ blueprintId: service.blueprint_id })
      toast('success', 'Blueprint update started')

libs/domains/service-settings/feature/src/lib/service-general-settings/blueprint-general-settings/blueprint-general-settings.tsx:163

• The PR description promises a blueprint_settings_visited PostHog event, but this new settings page has no posthog.capture call and the event name does not exist elsewhere in the checkout. Add the visit event when the Blueprint configuration page is displayed so the advertised analytics is actually emitted.

function BlueprintGeneralSettingsContent({ service, environmentId, organizationId }: BlueprintGeneralSettingsProps) {
  const { closeModal, openModal } = useModal()
  const { data, isLoading } = useBlueprint({ blueprintId: service.blueprint_id })
  const { data: persistedVariables = [], isLoading: isVariablesLoading } = useBlueprintVariables({
    blueprintId: service.blueprint_id,

libs/domains/service-settings/feature/src/lib/service-general-settings/blueprint-general-settings/blueprint-general-settings.tsx:83

• Blueprint settings drops repository metadata for Helm Blueprint services because this helper only handles Terraform. The existing overview extraction handles Helm Git sources via service.source.git.git_repository (service-header.tsx:193), so the settings page shows no catalog repository for that supported service type.

function getBlueprintGitRepository(service: BlueprintService) {
  return service.serviceType === 'TERRAFORM' ? service.terraform_files_source?.git?.git_repository : undefined
}

libs/domains/service-settings/feature/src/lib/service-general-settings/blueprint-general-settings/blueprint-general-settings.tsx:239

• The settings form only derives kind === 'variable' fields here. The creation flow also renders overridable contextVariable fields (blueprint-configuration-view.tsx:207-247), so those fields disappear from this page and Overrides is disabled when a Blueprint has context overrides but no optional variables. Existing Blueprint services with those overrides cannot view or edit them.

  const requiredFields = fields.filter(isRequiredVariableField)
  const optionalFields = fields.filter(isOptionalVariableField)

libs/domains/service-settings/feature/src/lib/service-general-settings/blueprint-general-settings/blueprint-general-settings.tsx:191

• When the catalog manifest request fails, data remains undefined and isLoading becomes false, but isError is ignored and catalogFields defaults to an empty array. The page then renders an apparently valid empty configuration instead of an error/retry state, and can allow a user to continue without seeing the manifest.

  const { data: catalogFields = [], isLoading: isCatalogManifestLoading } = useBlueprintCatalogServiceManifest({
    organizationId,
    provider,
    serviceFamily,
    serviceVersion,

libs/domains/service-settings/feature/src/lib/service-general-settings/blueprint-general-settings/blueprint-general-settings.tsx:329

• The preview is stored in the root ModalProvider, but this component does not close it when the settings route unmounts. Using browser Back or another route change while this non-dismissible modal is open leaves the preview mounted over the new route, with callbacks captured from the old page.

    openModal({
      content: (
        <>
          <Dialog.Title className="sr-only">Preview changes</Dialog.Title>
          <BlueprintPreview

libs/domains/service-settings/feature/src/lib/service-general-settings/blueprint-general-settings/blueprint-general-settings.tsx:305

• This catch covers both mutations. If updateBlueprint succeeds but deployBlueprint fails, the persisted configuration is rolled back from the optimistic cache, so the page immediately shows stale values even though the update was saved. Roll back only when the update mutation fails and retain the optimistic values for a deploy-only failure.

    try {
      await updateBlueprint({ blueprintId: service.blueprint_id, payload })
      await deployBlueprint({ blueprintId: service.blueprint_id })
      toast('success', 'Blueprint update started')
    } catch {

libs/domains/service-settings/feature/src/lib/service-general-settings/blueprint-general-settings/blueprint-general-settings.tsx:345

• min(50vw, 900px) makes this modal only 160px wide on a 320px viewport, while the content and footer each add 64px of horizontal padding. The preview and action buttons can overflow and become unusable on narrow screens; use a viewport-safe minimum such as min(900px, calc(100vw - 32px)).

        width: 'min(50vw, 900px)',

libs/domains/services/feature/src/index.ts:125

• These three exports are already present in this barrel at lines 34, 43, and 44. Re-exporting them again adds no API and makes the index harder to maintain; keep only the new exports in this block.

export * from './lib/hooks/use-blueprint/use-blueprint'
export * from './lib/hooks/use-deploy-blueprint/use-deploy-blueprint'
export * from './lib/hooks/use-preview-blueprint-update/use-preview-blueprint-update'
export * from './lib/hooks/use-update-blueprint/use-update-blueprint'

• Files reviewed: 33/34 changed files
• Comments generated: 7
• Review effort level: Lite